Notes on Unix features


Links:

A link is a "hard link" or a "symbolic link".

Unix divides what we think of as a "directory entry" into two things: the
directory entry itself contains the file's name and a pointer to an inode,
in which what we think of as directory information is held.

This makes it possible for several different directory entries to point to
the same inode, thus enabling the same file to be called by different names;
these are hard links.

A symbolic link is a special kind of inode which contains the path-name of
another object: this might be an absolute path-name, or a relative one - if
the latter, it is interpreted relative to its own position in the directory
hierarchy. The new path-name is prepended to the rest of the path-name which
is currently being looked up, and look-up continues.

Thus a symbolic link is, in many ways, like an image filing system - in that
the user can "step into" it - but when he's arrived, he *really* is at
another location in the filing system - perhaps, even, in a different filing
system altogether. FileSwitch must handle these things - presumably, ReadInfo
must return a further "object type" as "symbolic link", and there must be a
further directory attribute "symbolic link name".

Presumably, a symbolic link can specify/be a file as well as a directory.

We could implement this as an IFS - called SYMFS, say:

  - When a request is made to open a file inside a SYMFS image, SYMFS simply
    re-calls FSw to open the corresponding file defined by the contents of
    the image file!

But this could lead to a large number of SYMFS open images - when would they
be closed?* How would symbolic links be created? It also means that the link
name would be stored inside a file instead of the directory entry - probably
an undesirable overhead.

 [* Actually, this is a problem with all IFS images - it appears from my
    experiments that they are never closed until necessary, once they have
    been opened. ]


Quotas:

Quotas are on a per-user per-filesystem basis; both a "soft" and "hard" limit
are set, with users being warned when the soft limit is exceeded, and only
inhibited when the hard limit is reached.

Quota information is held in a file - which is conventionally called "quotas"
and lives in the root directory of the filesystem. For each user, Unix holds:

   - soft limit
   - hard limit
   - current value
   - number of soft warnings left


Tricks:

1) When looking up an object name inside a directory, start the search from
   where you left off before - there's a good chance that the client is
   searching in a linear way through the directory. (This is good even if
   he's searching in reverse alphabetical order, of course).

2) Use a "capability" when cacheing mappings that may become invalid. For
   example, suppose we cache path names against the disc address of the
   corresponding directory entries. Whenever a new directory entry is
   created - or an existing one moved - a new unique value is stored inside
   it, called a capability. When a cache entry is created, this capability
   value is stored with the address of the directory entry. When a cache
   entry is accessed, its capability is compared to the one in the directory
   entry itself - only if they are the same is the cache entry valid.
